Computers and computer systems have become ubiquitous. With the great range of computer hardware and software available, it has become important to set a number of standards for connecting various computer devices and communicating among them.
The computer industry has formed organizations of member companies to provide standards that permit compatibility and interoperability. Standards are now available for hardware and software connection between computers and peripherals, for example. Internal computer devices such as disk drives and input/output devices, and external products such as portable devices are attached to computers with standard interface cables and use standard communication protocols. Some widely adopted examples include USB, ATA, and Serial ATA (SATA or eSATA) interfaces.
In each of these systems, the host initiates operations and sends commands to the device, and the device responds to host commands following pre-defined protocols. There is no provision in these interfaces for a device to initiate a command or operation to a host. A device can only send information to a host that has been requested by a host-sent command or otherwise directly caused by a host action.
Such protocols use asymmetric interfaces where host and devices have defined roles of command and response (e.g., the host commands and the device responds) and are unlike peer-to-peer communication protocols where a unit can operate as both an initiator and as a target. SCSI is one standard interface that provides this peer-to-peer support.
Some system interfaces may allow for hardware notification between units via the host to device cable, however new interfaces favor serial communication that cannot provide a dedicated signal on the cable, and are not provided in systems such as Serial ATA or USB.
In a system with a host and a device where there is no provision for a device to notify a host of an important event at any time, the device has only unfavorable options. For example, upon failure conditions or events from which a device cannot recover, some devices may resort to self resetting or aborting outstanding commands in order to force a host to take notice and hopefully recover. This may cause catastrophic loss of data or result in an inoperable system. System timeouts or resets are a last resort to attempt recovery. Additionally, device to host notifications may be desirable before a situation becomes critical, such as environmental conditions or recoverable errors.
FIG. 1 illustrates a system 10 employing a host computer 11, a device 13, and an optional interconnect cable 12, allowing communication between the host computer 11 and device 13. The communication of FIG. 1 may comprise, for example, a Universal Serial Bus, AT Attachment, Serial Attached SCSI, or Serial ATA communication interface. Alternatively, some devices 13 plug directly into a host 11 without the need for a cable 12 and operate in the same manner. The host computer 11 may be any system that can send commands to the device 13. The host computer may be, for example, a desktop computer, notebook computer, or an application specific controller.
The interface between the host computer 11 and the device 13 may be a Universal Serial Bus interface, commonly referred to as a USB interface. The USB interface is also referred to as USB-1, USB-2 or USB-3, and future revisions are expected. Devices may support command queuing, and incorporate a command queue 14. The device 13 may be, for example, an I/O device such as keyboard, printer or mouse; storage device such as a disk drive, solid state drive, CD or DVD player; a communication device such as modems; or a personal entertainment device such as a music or video player.
FIG. 2 illustrates a system 20 employing a host computer 11 connected with a cable 12 to a host side of a hub 15, and devices 13 connected to a device side of the hub 15 with optional cables 12. The hub provides expansion ports so that multiple devices can connect to a single host port. In the system shown in FIG. 2, the host computer is the communication host; however, the devices are physically connected to the hub 15. The hub provides the physical interface to the devices and will appear to a device as a host. Hubs as shown in FIG. 2 are well known in the art and are widely available. References to hosts or host computers hereinafter may comprise a directly connected host as shown in FIG. 1, or a host connected through a hub as shown in FIG. 2.
FIG. 3 illustrates a flow chart of a device receiving a queued command. Beginning in step 300, a device is operating in a system with a host. In block 305, the device checks for a command reception from the host. If no new commands have been received (block 310) the device advances to block 315 to determine if there are any outstanding commands in the command queue. If the queue is empty, the device returns to 305 to continue checking for new commands.
If a new command was received in block 310, the device checks the command and its associated queue command tag validity in block 325. If the command is invalid or the tag is invalid, the device responds to the host by sending an error status in block 320. If the command and tag are valid, the device accepts the command (block 330) for execution. The device will add the command into the device command queue with any other outstanding commands waiting for completion. In block 340, the device will make a determination which command should be executed next and may reorder the queue for optimal performance as needed, although reordering is not required. The device then executes a command from the command queue in 345.
The flow chart shown in FIG. 3 is one example of a queued command process. Alternative embodiments might, for example, perform command reception, queue ordering, and/or command execution as simultaneous operations to provide improved performance.